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I. REAL PARTY IN INTEREST 

The real party in interest for this appeal is: 

Hewlett-Packard Development Company, L.P., a Texas Limited Partnership having its 
principal place of business in Houston, Texas. 

II. RELATED APPEALS AND INTERFERENCES 

There are no appeals, interferences, or judicial proceedings which will directly affect or 
be directly affected by or have a bearing on the Board's decision in this appeal. 

III. STATUS OF CLAIMS 

A. Total Number of Claims in Application 
There are 37 claims pending in application. 

B. Current Status of Claims 



1. Claims canceled: None 

2. Claims withdrawn from consideration but not canceled: None 

3. Claims pending: 1-37 

4. Claims allowed: None 

5. Claims rejected: 1-37 
C. Claims On Appeal 

The claims on appeal are claims 1-37 
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IV . STATUS OF AMENDMENTS 

A first Office Action was mailed for this application September 22, 2004. In response, 
Applicant filed an Amendment on December 22, 2004, which presented an amendment to claim 
5. A Final Office Action was then mailed April 20, 2005. Applicant did not file an amendment 
in response to the Final Office Action, but instead filed a Notice of Appeal on July 19, 2005 and 
filed a supporting Appeal Brief on September 19, 2005. The rejection at issue in that appeal was 
that all. of claims 1-37 stood rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. 
Patent No. 6,775,692 issued to Albert et al {"Albert"). 

In response to such Appeal Brief, the Examiner did not submit an Answer, but instead 
reopened prosecution and mailed an Office Action dated April 6, 2006 which raised a Restriction 
Requirement. Applicant traversed the Restriction Requirement in a response dated May 5, 2006, 
and the Restriction Requirement was withdrawn in an Office Action mailed July 27, 2006. 
However, the July 27, 2006 Office. Action rejected the claims on new grounds, namely rejecting 
all of claims 1-37 under 35 U.S.C. § 103(a) as being unpatentable over Albert in view of U.S. 
Patent No. 5,774,660 issued to Brendel et al ("Brendel"). Applicant submitted a response on 
October 25, 2006 which did not amend any of the claims, but instead pointed out that Brendel 
does not correct the deficiencies of Albert that were noted in the previous Appeal. 

A Final Office Action was then mailed January 12. 2007 that maintained the rejection of 
claims 1-37 under 35 U.S.C. § 103(a) as-being unpatentable over Albert in view of Brendel. 
Applicant did not file an amendment in response to the Final Office Action, but instead filed a 
Notice of Appeal, which this brief supports. Thus, the claims on appeal are those claims rejected 
in the Final Office Action mailed January 12, 2007, and a listing of those claims are provided in 
Appendix A hereto. 
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V. SUMMARY OF CLAIMED SUBJECT MATTER 

The following provides a concise explanation of the subject matter defined in each of the 
separately argued claims involved in the appeal, referring to the specification by page and line 
number and to the drawings by reference characters, as required by 37 C.F.R. § 41.37(c)(l)(v). 
Each element of the claims is identified by a corresponding reference to the specification and 
drawings where applicable. Note that the citation to passages in the specification and drawings 
for each claim element does not imply that the limitations from the specification and drawings 
should be read into the corresponding claim element. 

According to one claimed embodiment of the present invention, a method of TCP state 
migration in a communication network comprises establishing a TCP/IP communication session 
between a client computer (e.g., client 410 of Figure 4) and a first server computer (e.g., server 
450 of Figure 4). The first server computer is part of a plurality of server computers forming a 
web cluster containing information (e.g., web cluster 490 of Figure 4). The communication 
session is established for the transfer of data contained within the information. The method 
further comprises handing off the communication session to a selected server computer (e.g., 
server 452 of Figure 4, and see page 23, lines 9-13 of the specification) from the first server 
computer over a persistent control channel using TCP handoff modules (e.g., Upper TCP module 
522 and Bottom TCP module 524 of Figure 5C, and see page 8, line 25 - page 1 1, line 6, and 
page 29, line 27 - page 30, line 6 of the specification) that are dynamically loadable (see page 
17, line 24 - page 1 8, line 15 of the specification) within TCP/IP stacks in operating systems 
located at both the first server computer and the selected server computer, that implement a TCP 
handoff protocol that works within kernel levels of an existing TCP/IP protocol (see page 23, 
line 21 - page 26, line 29 of the specification). The method further comprises migrating a first 
TCP state of the first server computer to the selected server computer, and a second TCP state of 
the selected server computer to the first server computer over the control channel (e.g., page 10, 
line 26 - page 11, line 28 of the specification). 

In one embodiment, establishing the TCP/IP communication session further comprises 
receiving a SYN packet from the client at a first BTCP module located at the first server 
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computer (block 1010 of Figure 10); sending the SYN packet upstream to a first TCP module 
located above the first BTCP module in a first operating system of the first server computer 
(block 1020 of Figure 10); receiving a first SYN/ACK packet from the first TCP module (block 
1030 of Figure 10); parsing the first initial TCP state from the first SYN/ACK packet, including 
a first initial sequence number for the first TCP module associated with the TCP/IP 
communication session (block 1040 of Figure 10); sending the SYN/ACK packet to the client 
(block 1050 of Figure 10); receiving an ACK packet from the client at the first BTCP module 
(block 1060 of Figure 10); sending the ACK packet to the first TCP module (block 1070 of 
Figure 10); receiving a web request packet associated with the TCP/IP communication session at 
the first BTCP module at the first server computer (block 1080 of Figure 10); and storing the 
SYN, ACK and the web request packet at the first server computer (block 1090 of Figure 10). 

In one embodiment, handing off the communication session further comprises examining 
content of the web request packet; determining which of the plurality of server computers, a 
selected server computer, can best process the WEB request packet, based on the content (page 
10, lines 7-16 of the specification); sending a handoff request from said first BTCP module to a 
second BTCP module at the selected server computer over the control channel, if the selected 
server computer is not the first server computer; including the SYN packet and the ACK packet 
in the handoff request packet; changing a first destination IP address of said SYN packet to a 
second IP address of said selected server computer, at said second BTCP module; sending said 
SYN packet to said second TCP module; receiving a second SYN/ACK packet at said second 
BTCP module; parsing said second initial TCP state from said second SYN/ACK packet, 
including a second initial sequence number, for said second TCP module, that is associated with 
said TCP/IP communication session; changing a second destination IP address of said ACK 
packet to said second IP address, at said second BTCP module; updating said ACK packet to 
reflect said second TCP state of said selected server computer in said communication session; 
sending said ACK packet that is updated to said second TCP module; and sending a handoff 
acknowledgment message to said first BTCP module. 
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According to another claimed embodiment, a method of TCP state migration in a 
communication network comprises establishing a TCP/IP communication session between a 
client computer (e.g., client 410 of Figure 4) and a first server computer (e.g., server 450 of 
Figure 4). The first server computer is part of a plurality of server computers forming a web 
cluster containing information (e.g., web cluster 490 of Figure 4), and the communication 
session, is established for the transfer of data contained within the information. The method 
further comprises monitoring traffic associated with establishing said TCP/IP communication 
session to understand a first initial TCP state of the first server computer associated with the 
TCP/IP communication session, at a first bottom-TCP (BTCP) module at the first server 
computer (Bottom TCP module 524 of Figure 5 and BTCP module 830 of Figure 8, and see page 
9, lines 16-20 and page 11, lines 8-1 1 of the specification). The method further comprises 
receiving a web request associated with the TCP/IP communication session at the first BTCP 
module at the first server computer (block 910 of Figure 9 and block 1310 of Figure 13, and see 
page 10, lines 7-8 of the specification). The method further comprises examining content of the 
web request, and determining which of the plurality of server computers ("a selected server 
computer") can best process the web request, based on the content (block 930 of Figure 9, and 
see page 10, lines 13-16 of the specification). The method further comprises handing off the 
communication session to the selected server (e.g., server 452 of Figure 4) computer from the 
first server computer over a persistent control channel, if the selected server computer is not the 
first server computer (see page 10, line 26 - page 1 1, line 28 and page 23, lines 9-13 of the 
specification). The method further comprises monitoring traffic associated with handing off the 
TCP/IP communication session to understand a second initial TCP state of the selected server 
computer associated with the TCP/IP communication session, at a second BTCP module at the 
selected server computer (e.g., BTCP module 870 of Figure 8, and see page 12, lines 1-13 of the 
specification). The method further comprises migrating the first initial TCP state to the selected 
server computer over the control channel, such that the second BTCP module can calculate a first 
TCP state for the first server computer in the TCP/IP communication session (e.g., page 1.2, line 
15 - page 13, line 8 of the specification). The method further comprises sending a second initial 
TCP state of the selected server computer to the first BTCP module (e.g., BTCP module 830 of 
Figure 8), such that the first BTCP module can calculate a second TCP state for the selected 
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server computer in the TCP/IP communication session. The method further comprises 
forwarding data packets received at the first BTCP module from the client to the selected server 
computer, by changing the data packets to reflect the second TCP state and a second IP address 
of the selected server computer (e.g., block 1320 of Figure 13, and see page 1.2, line 15 - page 
13, line 8 of the specification). The method further comprises sending response packets from the 
selected server computer directly to the client computer (see Figures 3 and 4) by changing the 
response packets to reflect the first TCP state and a first IP address of the first server computer 
(e.g., block 1440 of Figure 14, and see page 12, line 15- page 13, line 8 of the specification). 
And, the method further comprises terminating the TCP/IP communication session at the first 
server computer when the TCP/IP communication session is closed (e.g., page 13, lines 10-19). 

According to another claimed embodiment, a server computer comprises an upper TCP 
(UTCP) module (e.g., UTCP module 522 of Figure 5C, and UTCP modules 810 and 850 of 
Figure 8) located above a TCP module (e.g., TCP module 520 of Figures 5B and 5C S and TCP 
modules 820 and 860 in Figure 8) in an operating system of the server computer. The server 
computer further comprises a bottom TCP (BTCP) module (e.g., BTCP module 524 of Figure 
5C, and BTCP modules 830 and 870 of Figure 8) located below the TCP module. The UTCP, 
TCP, and BTCP modules implement a method of handing off a communication session between 
a first node (e.g., server 450 of Figure 4, and "front-end" node of Figure 8) and second node 
(e.g., server 452 of Figure 4, and "back-end" node of Figure 8) in a cluster network (e.g., cluster 
490 of Figure 4) that works within the kernel level of an existing TCP/IP protocol, by migrating 
TCP states associated with the first and second nodes (see page 10, line 26 - page 12, line 13 of 
the specification). 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Claims 1-37 are rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent 
No. 6,775,692 issued to Albert et al (hereinafter "Albert) in view of U.S. Patent No. 5,774,660 
issued to Brendel et al. (hereinafter "Brendet). 

VII. ARGUMENT 

Appellant respectfully traverses the outstanding rejections of the pending claims, and 
requests that the Board reverse the outstanding, rejections in light of the remarks contained 
herein. Below, Appellant argues many of the rejected claims separately. Thus, Appellant 
respectfully asserts that separately argued claims do not stand or fall together, see 37 C.F.R. § 
41.37(c)(l)(vii). 

All of claims 1-37 were previously rejected in a Final Office Action mailed April 20, 
2005 as being anticipated under 35 U.S.C. § 102(e) by Albert. In response, Applicant appealed 
the rejection to the Board and submitted an Appeal Brief presenting arguments regarding why 
the claims are not anticipated by Albert, In response to the Appeal Brief, the Examiner has 
reopened prosecution and now rejects the claims as being unpatentable over Albert in view of 
Brendel. 

Appellant respectfully submits that Brendel does not cure the deficiencies of Albert for 
the reasons discussed below. In particular, Brendel is discussed in the Background section of the 
present application (see page 5, line 25 - page 6, line 12 of the present application) and is noted 
as disclosing an inefficient mechanism for transferring TCP states that requires use of a 
proprietary protocol that is known only to the application level, which embodiments of the 
present invention overcome. Thus, for the reasons discussed further below, the combination of 
Brendel with Albert fails to render the claims unpatentable. As such, Appellant respectfully 
requests that the rejections be overturned and this application be passed to allowance. 

The test for non-obvious subject matter is whether the differences between the subject 
matter and the prior art are such that the claimed subject matter as a whole would have been 
obvious to a person having ordinary skill in the art to which the subject matter pertains. The 
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United States Supreme Court in Graham v. John Deere and Co. , 383 U.S. 1 (1966) set forth the 
factual inquiries which must be considered in applying the statutory test: (1) determining of the 
scope and content of the prior art; (2) ascertaining the differences between the prior art and the 
claims at issue; and (3) resolving the level of ordinary skill in the pertinent art. As discussed 
further hereafter, Applicant respectfully asserts that the claims include non-obvious differences 
over the cited art. 

As discussed further below, when considering the scope and content of the applied Albert 
and Brenckl references there are significant differences between the applied combination and the 
claims, as the applied combination fails to disclose all elements of the claims. Thus, considering 
the lack of disclosure in the applied combination of all elements of the claims, one of ordinary 
skill in the art would not find the claims obvious under 35 U.S.C. §103, and therefore the 
rejections should be overturned. 

Independent Claim 1 

Independent claim 1 recites: 

In a communication network, a method of TCP state migration comprising 
the steps of: 

a) establishing a TCP/IP communication session between a client 
computer and a first server computer, said first server computer part of a plurality 
of server computers forming a web cluster containing information, said 
communication session established for the transfer of data contained within said 
information; 

b) handing off said communication session to a selected server 
computer from said first, server computer over a persistent control channel using 
TCP handoff modules that are dynamically loadable within TCP/IP stacks in 
operating systems located at both said first server computer and said selected 
server computer, that implement a TCP handoff protocol that works within kernel 
levels of an existing TCP/IP protocol ; and 

c) migrating a first TCP state of said first server computer to said 
selected server computer, and a second TCP state of said selected server computer 
to said first server computer over said control channel. (Emphasis added). 

The combination of Albert and Brendel fails to teach or suggest all elements of 



independent claim 1. For the reasons discussed at length in the Appeal Brief of January 5, 2006, 
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Albert fails to disclose at least: 

A) TCP hando IT modules that are dynamically loadable within TCP/IP stacks in operating 
systems located at both said first server computer and said selected server computer; 

B) handing off said communication session; and 

C) a persistent control channel. 

The Final Office Action appears to concede that Albert fails to teach or suggest "b) 
handing off said communication session, to a selected server computer from said first server 
computer over a persistent control channel using TCP handoff modules that are dynamically 
loadable within TCP/IP stacks in operating systems located at both said first server computer and 
said selected server computer, that implement a TCP handoff protocol that works within kernel 
levels of an existing TCP/IP protocol", see page 3 of the Final Office Action. However, the 
Final Office Action asserts that Brendel discloses this element of the claim. Appellant 
respectfully disagrees, as discussed below. 

The present application briefly discusses Brendel at page 5, line 25 - page 6, line 12 as 
follows: 

Previously, various mechanisms for transferring TCP states were 
implemented, including using a separate proprietary protocol at the application 
layer of an operating system. For example, in the Brendel et al. patent (U.S. 
5,774,660), incoming packets to the front-end node have their protocol changed 
from TCP/IP protocol to a non-TCP/IP standard that is only understood by the 
proprietary protocol located at the application layer. Later, the packets are 
changed back to the TCP/IP protocol for transmission to the back-end web server. 
Thus, the Brendel et al. patent reduces processing efficiency by switching back 
and forth between the user-level and kernel level layers of the operating system. 

Thus, a need exists for a more efficient design for implementing a 
mechanism for transferring TCP states in a web server cluster. 

Thus, the present application expressly recognized that Brendel fails to provide TCP 
handoff modules within TCP/IP stacks in operating systems that implement a TCP handoff 
protocol that works within kernel levels of an existing TCP/IP protocol. Instead, Brendel 
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requires that incoming packets be changed into a proprietary protocol that is understood only at 
the application layer. For instance, Brendel explains at col. 13, lines 40-46 thereof: 

Modified TCP/IP stack 82 contains the standard TCP and IP modules with 
some modifications explained later. One modification is that incoming packets 
from the Internet have their protocol changed from TCP to a proprietary "1XP" 
protocol. Since this IXP protocol is unknown to the standard TCP and IP layers, 
il is sent directly up to application layer 80 containing the load balancer. 

Thus, Brendel appears to disclose a system in which the TCP/IP stack of an operating 
system is modified so as to change incoming packets from the TCP protocol to a proprietary 
protocol that is understood only at the application layer, rather than implementing TCP handoff 
modules within the TCP/IP stack to implement a TCP handoff protocol as recited by claim 1. 

Thus, for at least the above reasons, the combination of Albert and Brendel fails to 
disclose all elements of claim 1. As such, the rejection of claim 1 should be overturned, and 
claim 1 should be passed to allowance. 
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Independent Claim 11 

Independent claim 1 1 recites: 

In a communication network, a method of TCP state migration comprising 
the steps of: 

a) establishing a TCP/IP communication session between a client 
computer and a first server computer, said first server computer part of a plurality 
of server computers forming a web cluster containing information, said 
communication session established for the transfer of data contained within said 
information; 

b) monitoring traffic associated with establishing said TCP/IP 
communication session to understand a first initial TCP state of said first server 
computer associated with said TCP/IP communication session, at a first bottom- 
TCP (BTCP) module at said first server computer; 

c) receiving a web request associated with said TCP/IP 
communication, session at said first BTCP module at said first server computer; 

d) examining content of said web request; 

e) determining which of said plurality of server computers, a selected 
server computer, can best process said web request, based on said content; 

f) handing off said communication session to said selected server 
computer from said first server computer over a persistent control channel, if said 
selected server computer is not said first server computer; 

g) monitoring traffic associated with handing off said TCP/IP 
communication session to understand a second initial TCP state of said selected 
server computer associated with said TCP/IP communication session, at a second 
BTCP module at said, selected server computer; 

h) migrating said first initial TCP state to said selected server 
computer over said control channel, such that said second BTCP module can 
calculate a first TCP state for said first server computer in said TCP/IP 
communication session; 

i) sending a second initial TCP state of said selected server computer 
to said first BTCP module, such that said first BTCP module can calculate a 
second TCP state for said selected server computer in said TCP/IP 
communication session; 

j) forwarding data packets received at said first BTCP module from 
said client to said selected server computer, by changing said data packets to 
reflect said second TCP state and a second IP address of said selected server 
computer; 

k) sending response packets from said selected server computer 
directly to said client computer by changing said response packets to reflect said 
first TCP state and a first IP address of said first server computer; and 
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1) terminating said TCP/IP communication session at said first server 
computer when said TCP/IP communication session is closed. 

The combination of Albert and Brendel fails to teach or suggest all elements of 
independent, claim 1 1 . As discussed further in the Appeal Brief of January 5, 2006, Albert fails 
to disclose at least: 

A) a first bottom-TCP (BTCP) module at said first server computer, and a second BTCP 
module at said selected server computer; 

B) examining content of said web request and determining which of said plurality of 
server computers, a selected server computer, can best process said web request, based on said 
content; 

C) sending response packets from said selected server computer directly to said client 
computer; 

D) handing off said communication session; and 

E) a persistent control channel. 

Further, Brendel fails to teach or suggest at least a first bottom-TCP (BTCP) module at 
said first server computer, and a second BTCP module at said selected server computer, as 
recited by claim 1 1 . For instance, as discussed above with claim 1 , Brendel does not teach or 
suggest any such BTCP modules, but instead appears to disclose a modified TCP/IP stack that 
changes an incoming packet's protocol to a proprietary protocol that is unknown to the TCP/IP 
stack for handling at the application level. 

Thus, for at least the above reasons, the combination of Albert and Brendel. fails to 
disclose all elements of claim 1 1. As such, the rejection of claim 1 1 should be overturned, and 
claim 1 1 should be passed to allowance. 
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independent Claim 26 

Independent claim 26 recites: 

A server computer comprising: 

an upper TCP (UTCP) module located above a TCP module in an 
operating system of said sewer computer; 

a bottom TCP (BTCP) module located below said TCP module, said 
UTCP, TCP, and BTCP modules implementing a method of handing off a 
communication session between a first node and second node in a cluster network 
that works within the kernel level of an existing TCP/IP protocol, by migrating 
TCP states associated with said first and second nodes. 

The combination of Albert and Brendel fails to teach or suggest all elements of 
independent claim 26. As discussed further in the Appeal Brief of January 5, 2006, Albert fails 
to disclose the recited UTCP and BTCP modules. 

Further, Brendel fails to disclose the UTCP and BTCP modules. For example, Brendel 
does not disclose UTCP, TCP, and BTCP modules that implement a method of handing off a 
communication session between a first node and second node in a cluster network that works 
within the kernel level of an existing TCP/IP protocol as recited by claim. 26. For instance, as 
discussed above with claim 1, Brendel does not disclose any such modules that implement, 
handing off a communication session that works within the kernel level of an existing TCP/IP 
protocol, but instead appears to disclose a modified TCP/IP stack that changes an incoming 
packet's protocol to a proprietary protocol that is unknown to the TCP/IP stack for handling at 
the application level. 

Thus, for at least the above reasons, the combination of Albert and Brendel fails to 
disclose all elements of claim 26. As such, the rejection of claim 26 should be overturned, and 
claim 26 should be passed to allowance. 
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Dependent Claim 2 

Claim 2 depends from claim 1 and thus inherits all elements of claim I . Accordingly, 
claim 2 is allowable over the combination of Albert in view of Brendel at least for the reasons 
discussed above with claim 1 . Additionally, claim 2 further recites: 

The method as described in Claim 1, wherein said step a) comprises the 
steps of: 

receiving a SYN packet from said client at a first BTCP module located at 
said first server computer; 

sending said SYN packet upstream to a first TCP module located above 
said first BTCP module in a first operating system, of said first server computer; 

receiving a first SYN/ACK packet from said first TCP module; 

parsing said first initial TCP state from said first SYN/ACK packet, 
including a first initial sequence number for said first TCP module associated with 
said TCP/IP communication session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said first BTCP module; 

sending said ACK packet to said first TCP module; 

receiving a web request packet associated with said TCP/IP 
communication session at said first BTCP module at said first server computer; 

storing said SYN, ACK and said web request packet at said first server 
computer. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 2. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 2 {see pages 4-5 of the Final Office Action), as the reasoning for rejecting claim 2 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 2 was rejected as 
being anticipated by Albert), However, Albert fails to disclose all elements of claim 2. For 
instance, Albert fails to disclose at least the recited first BTCP module located at said first server 
computer. Further, Brendel does not appear to be relied upon in the rejection of claim 2 as 
disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 2 be overturned. 
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Dependent Claim 3 

Claim 3 depends from claim 2, which depends from claim 1, and thus claim 3 inherits all 
elements of claims 1 and 2. Accordingly, claim 3 is allowable over Albert in view of Brendel at 
least for the reasons discussed above with claims 1 and 2. Additionally, claim 3 further recites: 

The method as described in Claim 2, wherein said step b) comprises the 
steps of: 

examining content of said web request packet ; 

determining which of said plurality of server computers, a selected server 
computer, can best process said WEB request packet based on said content; 

sending a handoff request from said first BTCP module to a second BTCP 
module at said selected server computer over said control channel, if said selected 
server computer is not said first server computer; 

including said SYN packet and said ACK packet in said handoff request 

packet; 

changing a first destination IP address of said SYN packet to a second IP 
address of said selected server computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second SYN/ ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ACK packet, 
including a second initial sequence number, for said second TCP module, that is 
associated with said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said 
second IP address, at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected 
server computer in said communication session; 

sending said ACK packet that is updated to said second TCP module; and 

sending a handoff acknowledgment message to said first BTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 3. The Final Office Action appears to rely upon Albert as disclosing ail elements of 
claim 3 (see pages 5-6 of the Final Office Action), as the reasoning for rejecting claim 3 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 3 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 3. For 
instance. Albert fails to teach at least the recited second BTCP module at said selected server 
computer. Further, as discussed below with independent claim 1 1, Albert fails to teach 
examining content of said web request packet and determining which of said plurality of server 
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computers, a selected server computer, can best process said WEB request packet, based on said 
content . Further, Brendel does not appear to be relied upon in the rejection of claim 3 as 
disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 3 be overturned. 

Dependent Claim 4 

Claim 4 depends from, claim 3, which depends from claim 2 which depends from 1, and 
thus claim 4 inherits all elements of claims 1, 2, and 3. Accordingly, claim 4 is allowable over 
Albert in view of Brendel at least for the reasons discussed above with claims 1-3. Additionally, 
claim 4 further recites: 

The method as described in Claim 3, wherein step c) comprises the steps 

of: 

monitoring traffic associated with establishing said TCP/IP 
communication session in step a), at said first BTCP module, to parse a first initial 
TCP state of said first server computer, said first initial TCP state associated with 
said TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over 
said control channel by including said first initial TCP state in said handoff 
request packet, said first initial TCP state including a first sequence number, such 
that said second BTCP module can calculate said first TCP state for said first 
server computer in said TCP/IP communication session. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 4. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 4 (see pages 6-7 of the Final Office Action), as the reasoning for rejecting claim 4 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 4 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 4. For 
instance, Albert fails to teach at least the recited "migrating said first initial TCP state to said 
second BTCP module over said control channel by including said first initial TCP state in said 
handoff request packet, said first initial TCP state including a first sequence number'. Further, 
Brendel does not appear to be relied upon in the rejection of claim 4 as disclosing these elements, 
nor does it do so. 
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Accordingly, Appellant respectfully requests that the rejection of claim 4 be overturned. 
Dependent Claim 5 

Claim 5 depends from claim 3, which depends from claim 2 which depends from 1, and 
thus claim 5 inherits all elements of claims 1,2, and 3. Accordingly, claim 5 is allowable over 
Albert in view of Brendel at least for the reasons discussed above with claims 1-3. Additionally, 
claim 5 further recites: 

The method as described in Claim 3, wherein step c) comprises the steps 

of: 

monitoring traffic associated with handing off said TCP/IP communication 
session at said second BTCP module, to parse a second initial TCP state of said 
selected server computer, said second initial TCP state associated with said 
TCP/IP communication session; and 

migrating said second initial TCP state of said selected server computer to 
said first BTCP module by including said second initial TCP state in said handoff 
acknowledgment packet, said second initial TCP state including a second initial 
sequence number, such that said first BTCP module can calculate said second 
TCP state for said selected server computer in said TCP/IP communication 
session. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 5. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 5 (see page 7 of the Final Office Action), as the reasoning for rejecting claim 5 appears to 
be the same as in the Final Office Action of April 20, 2005 (in which claim 5 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 5. For 
instance, Albert fails to teach at least the recited "migrating said second initial TCP state of said 
selected server computer to said first BTCP module by including said second initial TCP state in 
said handoff acknowledgment packet, said second initial TCP state including a second initial 
sequence number". Further, Brendel does not appear to be relied upon in the rejection of claim 5 
as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 5 be overturned. 



Dependent Claim 6 
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Claim 6 depends from claim 2, which depends from claim 1, and thus claim 6 inherits all 
elements of claims 1 and 2. Accordingly, claim 6 is allowable over Albert in view of Brendel at 
least for the reasons discussed above with claims 1 and 2. Additionally, claim 6 further recites: 

The method as described in Claim 2, comprising the further steps of: 
intercepting a connection indication message sent from said first TCP 
module to an application layer above said first TCP module at a first upper-TCP 
(UTCP) module, said connection indication message sent by said first TCP 
module upon establishing said communication session; and 

holding said connection indication message at said first UTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 6. The Final Office Action appears to rely wpon Albert as disclosing all elements of 
claim 6 (see pages 7-8 of the Final Office Action), as the reasoning for rejecting claim 6 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 6 was rejected as 
being anticipated by A lbert), However, Albert fails to disclose all elements of claim 6. For 
instance, Albert fails to teach at least the recited first upper TCP UTCP) module. Further, 
Brendel does not appear to be relied upon in the rejection of claim 6 as disclosing these elements, 
nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 6 be overturned. 
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Dependent Claim 7 

Claim 7 depends from claim 6, which depends from claim 2 which depends from claim 1, 
and thus claim 7 inherits all elements of claims 1 , 2, and 6. Accordingly, claim 7 is allowable 
over Albert in view of Brendel at least for the reasons discussed above with claims 1.2, and 6. 
Additionally, claim 7 further recites: 

The method as described in Claim 6, wherein said method comprises the 
further steps of: 

sending a reset packet from said first BTCP module upon receiving said 
handoff acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 
receiving incoming data packets from said client at said first BTCP 

module; 

changing said destination addresses of said incoming data packets to said 
second IP address; 

updating sequence numbers and TCP checksum in said data packets to 
reflect said second TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 7. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 7 {see pages 8-9 of the Final Office Action), as the reasoning for rejecting claim 7 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 7 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 7. For 
instance, Albert fails to teach at least the recited "sending a reset packet from said first BTCP 
module upon receiving said handoff acknowledgment packet to said first TCP module". Further, 
Brendel does not appear to be relied upon in the rejection of claim 7 as disclosing these elements, 
nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 7 be overturned. 
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Dependent Claim 8 

Claim 8 depends from claim 6, which depends from claim 2 which depends from claim 1, 
and thus claim 8 inherits all elements of claims 1, 2, and 6. Accordingly; claim 8 is allowable 
over Albert in view of Brendel at least for the reasons discussed above with claims 1, 2, and 6. 
Additionally, claim 8 further recites: 

The method as described in Claim 6, comprising the further steps of: 
sending notification from said first BTCP module to said first UTCP 

module to release said connection indication message, if said selected server 

computer is said first server computer; 

sending incoming data packets, including said web request packet, from 

said client, received at said first BTCP module, upstream. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 8. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 8 (see page 9 of the Final Office Action), as the reasoning for rejecting claim 8 appears to 
be the same as in the Final Office Action of April 20, 2005 (in which claim 8 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 8. For 
instance, Albert fails to teach at least the recited "sending notification from said first BTCP 
module to said first UTCP module to release said connection indication message, if said selected 
server computer is said first server computer". Further, Brendel does not appear to be relied 
upon in the rejection of claim 8 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 8 be overturned. 
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Dependent Claim 9 

Claim 9 depends from claim 1 and thus inherits all elements of claim 3 . Accordingly, 
claim 9 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 1 . Additionally, claim 9 further recites: 

The method as described in Claim 1 , comprising the further step of: 

intercepting outgoing response packets from said selected server computer 
at a second bottom TCP (B TCP) module located at said selected server computer; 

changing source addresses of said response packets to a first IP address of 
said first server computer: 

updating sequence numbers and TCP checksum in said response packets 
to reflect said first TCP state of said first server computer; and 

sending said response packets to said client. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 9. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 9 {see pages 9-10 of the Final Office Action), as the reasoning for rejecting claim 9 
appears to be the same as in the Final Office Action of April 20, 2005 (in which claim 9 was 
rejected as being anticipated by Albert). However, Albert fails to disclose all elements of claim 
9. For instance, Albert fails to teach at least the recited second bottom TCP (BTCP) module 
located at said selected server computer. Further, Brendel does not appear to be relied upon in 
the rejection of claim 9 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 9 be overturned. 
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Dependent Claim 10 

Claim 10 depends from claim 1 and thus inherits all elements of claim 1. Accordingly, 
claim 10 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 1. Additionally, claim 10 further recites: 

The method as described in Claim 1, comprising the further steps of: 
monitoring TCP/IP control traffic for said communication session at said 

second BTCP module; 

understanding when said communication session is closed at said second 

server computer; 

sending a termination message to said first server computer over said 
control channel; 

terminating said TCP/IP communication session at said first server 
computer by terminating a forwarding mode at said first BTCP module; and 

freeing data resources associated with said communication session at said 
first server computer. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 10. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 10 (see page 10 of the Final Office Action), as the reasoning for rejecting claim 10 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 10 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 10. For 
instance, Albert fails to teach at least the recited first and second bottom TCP (BTCP) modules. 
Further, Brendel does not appear to be relied upon in the rejection of claim 10 as disclosing these 
elements, nor does it do so. 

Accordingly, Appellant respectfully requests that, the rejection of claim 10 be overturned. 
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Dependent Claim 12 

Claim 12 depends from claim 1 1 and thus inherits all elements of claim 1 1. Accordingly, 
claim 12 is allowable over Albert in view of Brendei at least for the reasons discussed above with 
claim 1 1 . Additionally, claim 12 further recites: 

The method as described in Claim 11, wherein said step a) comprises the 
steps of: 

receiving a packet from said client at said first BTCP module; 

sending said SYN packet upstream to a first TCP module located above 
said first BTCP module in a first operating system of said first server computer; 

receiving a first SYN/ACK packet from said first TCP module; 

parsing said first initial TCP state from said first SYN/ACK packet, 
including a first initial sequence number for said first TCP module associated 
with, said TCP/IP communication session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said first BTCP module: 

sending said ACK packet to said first TCP module; 

storing said SYN, ACK and said web request at said first server computer. 

The combination of Albert in view of Brendei fails to disclose all of the further elements 
of claim 12. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 12, as the reasoning for rejecting claim 12 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 12 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 12. For instance, Albert fails to teach at 
least the recited "sending said SYN packet upstream to a first TCP module located above said 
first BTCP module in a first operating system of said first server computer". Further, Brendei 
does not appear to be relied upon in the rejection of claim 12 as disclosing these elements, nor 



Accordingly, Appellant respectfully requests that the rejection of claim 12 be overturned. 
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Dependent Claim 13 

Claim 13 depends from claim 1 1 and thus inherits all elements of claim 11. Accordingly, 
claim 13 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 11. Additionally, claim 13 further recites: 

The method as described in Claim 1 1, wherein said step e) comprises the 
steps of: 

sending a handoff request packet from said first BTCP module to said 
second BTCP module over said control channel; 

including said SYN packet and said ACK packet in said handoff request 

packet; 

changing a first destination IP address of said SYN packet to a second IP 
address of said selected server computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second SYN/ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ACK packet, 
including a second initial sequence number, for said second TCP module, that is 
associated with said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said 
second IP address, at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected 
server computer in said communication session; 

sending said ACK packet that is updated to said second TCP module; and 

sending a handoff acknowledgment message to said first BTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 13. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 13, as the reasoning for rejecting claim 13 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 13 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 13. For instance, Albert fails to teach at 
least the recited "changing a second destination IP address of said ACK packet to said second IP 
address, at said second BTCP module ; . . .and sending a handoff acknowledgment message to 
said first BTCP module " (emphasis added). Further, Brendel does not appear to be relied upon 
in the rejection of claim 13 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 13 be overturned. 
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Dependent Claims 14-15 

Claims 14-15 each depend from claim 13, which depends from claim 1 1 . Thus, claims 
14 and 15 each inherit all elements of claims 1 1 and 13, and are therefore allowable over Albert 
in view of Brendel at least for the reasons discussed above with claims 11 and 13. Therefore, 
Appellant respectfully requests that the rejection of claims 14 and 15 be overturned. 

Dependent Claim 16 

Claim 16 depends from claim 13, which depends from claim 11, and thus claim 16 
inherits all elements of claims 1 1 and 13. Accordingly, claim 16 is allowable over Albert in view 
of Brenckl at least for the reasons discussed above with claims 1 1 and 13. Additionally, claim 
16 further recites: 

The method as described in Claim 13, comprising the further steps of: 
intercepting a connection indication message sent from said first TCP 
module to an application layer above said first TCP module at a first upper-TCP 
(UTCP) module, said connection indication message sent by said first TCP 
module upon establishing said communication session; and 

holding said connection indication message at said first UTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 16. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 16, as the reasoning for rejecting claim 16 appears to be the same as in the Final. Office 
Action of April 20, 2005 (in which claim 16 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 16. For instance, Albert fails to teach at 
least the recited first upper TCP (UTCP) module. Further, Brendel does not appear to be relied 
upon in the rejection of claim 16 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 16 be overturned. 

Dependent Claim 17 
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Claim 17 depends from claim 16, which depends from claim 13 which depends from 
claim 1 1, and thus claim 17 inherits all elements of claims 1 1, 13, and 16. Accordingly, claim 17 
is allowable over Albert in view of Brendel at least for the reasons discussed above with claims 
1 1, 13, and 1.6. Additionally, claim 17 further recites; 

The method as described in Claim 16, wherein step h) comprises the 
further steps of: 

sending a reset packet from said first BTCP module upon receiving said 
handoff acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 
receiving incoming data packets from said client at said first BTCP 

module; 

changing said destination addresses of said incoming data packets to said 
second IP address; 

updating sequence numbers and TCP checksum in said data packets to 
reflect said second TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

The combination of Albert in view of Brendel fails to disclose al l of the further elements 
of claim 17. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 17, as the reasoning for rejecting claim 17 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 17 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 17. For instance, Albert fails to teach at 
least the recited "sending a reset packet from said first BTCP module upon receiving said 
handoff acknowledgment packet to said first TCP module". Further, Brendel does not appear to 
be relied upon in the rejection of claim 17 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 17 be overturned. 
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Dependent Claim 18 

Claim 18 depends from claim 1 1 and thus inherits all elements of claim 1 1 . Accordingly, 
claim 18 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 1 1 . Additionally, claim 1 8 further recites: 

The method as described in Claim 11, wherein step k) comprises the steps 

of: 

intercepting outgoing response packets from said selected server computer 
at said second BTCP module; 

changing source addresses of said response packets to said first IP address; 

updating sequence numbers and TCP checksum in said response packets 
to reflect said first TCP state of said first server computer; and 

sending said updated response packets to said client. 

The combination of Albert m view of Brendel fails to disclose all of the further elements 
of claim 18. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 18, as the reasoning for rejecting claim 18 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 18 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 1 8. For instance, Albert fails to teach at 
least the recited "intercepting outgoing response packets from said selected server computer at 
said second BTCP module". Further, Brendel does not appear to be relied upon in the rejection 
of claim 18 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 18 be overturned. 
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Dependent Claim 19 

Claim 19 depends from claim 1 1 and thus inherits all elements of claim 1 1 . Accordingly, 
claim 19 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 11. Additionally, claim 19 further recites: 

The method as described in Claim 1 1, wherein step 1) comprises the steps 

of: 

monitoring TCP/IP control traffic for said communication session at said 
second BTCP module; 

understanding when said communication session is closed at said second 
server computer; 

sending a termination message to said first server computer over said 

control channel; 

terminating a forwarding mode at said first BTCP module; and 

freeing data resources associated with said communication session at said 

first server computer. 

The combination of Albert in view o f Brendel fails to disclose all of the further elements 
of claim 19. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 19, as the reasoning for rejecting claim 19 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 19 was rejected as being anticipated by Albert), 
However, Albert fails to disclose all elements of claim 19. For instance, Albert fails to teach at 
least the recited "monitoring TCP/IP control traffic for said communication session at said 
second BTCP module" and "terminating a forwarding mode at said first BTCP module". 
Further, Brendel does not appear to be relied upon in the rejection of claim 19 as disclosing these 
elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 19 be overturned. 
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Dependent Claim 20 

Claim 20 depends from claim 16, which depends from claim 13 which depends from 
claim 1 1, and thus claim 20 inherits all elements of claims 1 1, 13, and 16. Accordingly, claim 20 
is allowable over Albert in view of Brendel at least for the reasons discussed above with claims 
11,13, and 16. Additionally, claim. 20 further recites: 

The method as described in Claim 16 } comprising the further steps of: 
sending notification from said First BTCP module to said first UTCP 

module to release said connection indication message, if said selected server 

computer is said first server computer; and 

sending incoming data packets, including said web request, from said 

client, received at said first BTCP module, upstream. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 20. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 20, as the reasoning for rejecting claim 20 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 20 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 20. For instance, Albert fails to teach at 
least the recited "sending notification from said first BTCP module to said first UTCP module to 
release said connection indication message, if said selected server computer is said first server 
computer". Further, Brendel does not appear to be relied upon in the rejection of claim 20 as 
disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 20 be overturned. 
Dependent Claim 21 

Claim 21 depends from claim 1 1 and thus inherits all elements of claim 1 1. Accordingly, 
claim 21 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 11. Additionally, claim 21 further recites: 

The method as described, in Claim 1 1 , wherein each of said plurality of 
server computers is constructed similarly including BTCP modules located 
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downstream from TCP modules, and UTCP modules located upstream from TCP 
modules. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 21 . The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 21 , as the reasoning for rejecting claim 21 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim. 21 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 21. For instance, Albert fails to teach 
each of its server computers include BTCP modules located downstream from TCP modules, and 
UTCP modules located upstream from TCP modules. Again, Albert fails to teach the recited 
BTCP and UTCP modules. Further, Brendel does not appear to be relied upon in the rejection of 
claim 21 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 21 be overturned. 
Dependent Claim 22 

Claim 22 depends from claim 12, which depends from claim 1 1 . Thus, claim 22 inherits 
all elements of claims 1 1 and 12, and are therefore allowable over Albert in view of Brendel at 
least for the reasons discussed above with claims 1 1 and 12. Therefore, Appellant respectfully 
requests that the rejection of claim 22 be overturned. 

Dependent Claim 23 

Claim 23 depends from claim 22, which depends from claim 12 which, depends from 
claim 11. Thus, claim 23 inherits all elements of claims 1 1, 12, and 22. Accordingly, claim 23 
is allowable over Albert in view of Brendel at least for the reasons discussed above with claims 
11,12, and 22. Additionally, claim 23 further recites: 

The method as described in Claim 22, wherein said control channel allows 
for communication between all UTCP modules. 
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The combination of Albert in view oiBrendel fails to disclose all of the further elements 
of claim 23. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 23, as the reasoning for rejecting claim 23 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 23 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 23. For instance, Albert fails to teach 
each UTCP modules, and thus fails to teach a control channel that allows communication 
between all. of such UTCP modules. Further, Brendel does not appear to be relied upon in the 
rejection of claim 23 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 23 be overturned. 

Dependent Claims 24-25 

Claims 24-25 each depend from claim. 1 1, and thus claims 24 and 25 each inherit all 
elements of claim 11. Therefore, claims 24-25 are each allowable over Albert in view of Brendel 
at least for the reasons discussed above with claim 1 1 . As such, Appellant respectfully requests 
that the rejection of claims 24 and 25 be overturned. 

De pendent Claim 27 

Claim 27 depends from claim 26 and thus inherits all elements of claim 26. Accordingly, 
claim 27 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 26. Additionally, claim 27 further recites: 

The server computer as described in Claim 26, wherein said method 
comprises the steps of: 

a) establishing a TCP/IP communication session between a client 
computer and said server computer, said first node, said server computer part of a 
plurality of server computers forming said cluster network containing 
information, said communication session established for the transfer of data 
contained within said information; 

b) receiving a web request associated with said TCP/IP 
communication session at a first BTCP module at said server computer; 

c) examining content of said web request ; 

d) determining which of said plurality of server computers, a selected 
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server computer, can best process said web request, based on said content ; 

e) handing off said communication session to said selected server 
computer from said server computer over a persistent control channel , if said 
selected server computer is not said server computer; and 

f) migrating a first TCP state of said server computer to said selected 
server computer, and sending a second TCP state of said selected server computer 
to said server computer over said control channel. (Emphasis added). 

The combination of Albert in view of ' Brendel fails to disclose all of the further elements 
of claim 27. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 27, as the reasoning for rejecting claim 27 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 27 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 27. For instance, as discussed above with 
claim 1 1 } Albert fails to teach determining which of the plurality of server computers, a selected 
server computer, can best process a web request, based on content of the web request. As also 
discussed above with claim 1 1 , Albert fails to teach handing of a communication session over a 
persistent control channel. Further, Brendel does not appear to be relied upon in the rejection of 
claim 27 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 27 be overturned. 
Dependent Claim 28 

Claim 28 depends from claim 27, which depends from claim 26, and thus claim 28 
inherits all elements of claims 26 and 27. Accordingly, claim 28 is allowable over Albert in view 
of Brendel at least for the reasons discussed above with claims 26 and 27. Additionally, claim 
28 further recites: 

The server computer as described in Claim 27, wherein step a) of said 
method comprises the steps of: 

receiving, a SYN packet from said client at said BTCP module; 

sending said SYN packet upstream to said TCP module; 

receiving a first SYN/ACK packet from said TCP module; 

parsing a first initial TCP state from said first SYN/ACK packet, including 
a first initial sequence number for said TCP module associated with said TCP/IP 
communication session; 
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sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said BTCP module; 

sending said ACK packet to said TCP module; 

storing said SYN, ACK at said server computer. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 28. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 28, as the reasoning for rejecting claim 28 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 28 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 28. For instance, as discussed above, 
Albert fails to teach the BTCP module, and thus for at least this reason Albert fails to teach the 
above steps that involve such BTCP module. Further, Brendel does not appear to be relied upon 
in the rejection of claim 28 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 28 be overturned. 

Dependent Claim 29 

Claim 29 depends from claim 28, which depends from claim 27 which depends from 
claim 26, and thus claim 29 inherits all elements of claims 26-28. Accordingly, claim 29 is 
allowable over Albert in view of Brendel at least for the reasons discussed above with claims 26- 
28. Additionally, claim 29 further recites: 

The server computer as described in Claim 28, wherein said method 
comprises the steps of: 

sending a handoff request packet from said BTCP module to a second 
BTCP module over said control channel, said second BTCP module located 
below a second TCP module in a second operating system at said selected server 
computer; 

including said SYN packet and said ACK packet in said handoff request; 
receiving a handoff acknowledgment message at said BTCP module from 
said second BTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 29. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 29, as the reasoning for rejecting claim 29 appears to be the same as in the Final Office 
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Action of April 20, 2005 (in which claim 29 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 29. For instance, as discussed above, 
Albert fails to teach the recited BTCP modules, and thus for at least this reason Albert fails to 
teach the above steps that involve such BTCP modules. Further, Brendel does not appear to be 
relied upon in the rejection of claim 29 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 29 be overturned. 

Dependent Claim 30 

Claim 30 depends from claim 29, which depends from claim 28 which depends from 
claim 27 which depends from claim 26, and thus claim 30 inherits all elements of claims 26-29. 
Accordingly, claim 30 is allowable over Albert in view of Brendel at least for the reasons 
discussed above with claims 26-29. Additionally, claim 30 further recites: 

The server computer as described in Claim 29, wherein said step f) of said 
method comprises the steps of: 

monitoring traffic associated with establishing said TCP/IP 
communication session in step a), at said BTCP module, to parse a first initial 
TCP state of said server computer, said first initial TCP state associated with said 
TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over 
said control channel by including said first initial TCP state in said handoff 
request, said first initial TCP state including a first sequence number, such that 
said second BTCP module can calculate said first TCP state for said server 
computer in said TCP/IP communication session. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 30. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 30, as the reasoning for rejecting claim 30 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 30 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 30. For instance, as discussed above, 
Albert fails to teach the recited BTCP module and control channel, and thus for at least these 
reasons Albert fails to teach, the above steps that involve such BTCP modules and control 
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channel. Further, Brendel does not appear to be relied upon in the rejection of claim 30 as 
disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 30 be overturned. 
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Dependent Claim 31 

Claim 31 depends from claim 29, which depends from claim 28 which depends from 
claim 27 which depends from claim 26, and thus claim 3 1 inherits all elements of claims 26-29. 
Accordingly, claim 31 is allowable over Albert in view of Brendel at least for the reasons 
discussed above with claims 26-29. Additionally, claim 31 further recites: 

The server computer as described in Claim 29, wherein said method 
comprises the further steps of: 

intercepting a connection indication message sent from said first TCP 
module to an application layer above said first TCP module at a first upper-TCP 
(UTCP) module, said connection indication message sent by said first TCP 
module upon establishing said communication session; and 

holding said connection indication message at said first UTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 3 1 . The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 31, as the reasoning for rejecting claim 31 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 31 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 31. For instance, Albert fails to teach the 
recited first upper TCP (UTCP) module, and thus for at least this reason Albert fails to teach the 
above steps that involve such UTCP module. Further, Brendel does not appear to be relied upon 
in the rejection of claim 3 1 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 31 be overturned. 
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Dependent Claim 32 

Claim 32 depends from claim 3 1 , which depends from claim 29 which depends from 
claim 28 which depends from claim 27 which depends from claim 26, and thus claim 32 inherits 
all elements of claims 26-29 and 3 1 . Accordingly, claim 32 is allowable over Albert in view of 
Brendel at least for the reasons discussed above with claims 26-29 and 3 1 . Additionally, claim 
32 further recites: 

The computer system as described in Claim 31, wherein said method 
comprises the further steps of: 

sending a reset packet from said first BTCP module upon receiving said 
handoff acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 

receiving incoming data packets from said client at said first BTCP 
module; 

changing said destination addresses of said incoming data packets to said 
second IP address; 

updating sequence numbers and TCP checksum in said data packets to 
reflect said second TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 32. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 32. as the reasoning for rejecting claim 32 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 32 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 32, For instance, Albert fails to teach the 
recited "sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module" and "discarding said connection indication 
message at said first UTCP module". Further, Brendel does not appear to be relied upon in the 
rejection of claim 32 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 32 be overturned. 
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Dependent Claim 33 

Claim 33 depends from claim 31, which depends from claim 29 which depends from 
claim 28 which depends from claim 27 which depends from claim 26, and thus claim 33 inherits 
all elements of claims 26-29 and 31 . Accordingly, claim 33 is allowable over Albert in view of 
Brendel at least for the reasons discussed above with claims 26-29 and 31 . Additionally, claim 
33 further recites: 

The server computer as described in Claim 31, said method comprising the 
further steps of: 

sending notification from said BTCP module to said UTCP module to 
release said connection indication message, if said selected server computer is 
said server computer; 

sending incoming data packets, including said web request, from said 
client, received at said first BTCP module, upstream. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 33. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 33, as the reasoning for rejecting claim 33 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 33 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 33. For instance, Albert fails to teach the 
recited BTCP and UTCP modules, and thus for at least this reason Albert fails to teach the above 
steps involving such modules. Further, Brendel does not appear to be relied upon in the rejection 
of claim 33 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 33 be overturned. 
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Dependent Claim 34 

Claim 34 depends from claim 26, and thus inherits all elements of claim 26. 
Accordingly, claim 34 is allowable over Albert in view of Brendel at least for the reasons 
discussed above with claim 26. Additionally, claim 34 further recites: 

The server computer as described in Claim 26, said method comprising the 
further steps of: 

receiving a handoff request from a first BTCP module located at a first 
server computer within said cluster network over a persistent control channel, said 
first server computer having established a communication session with a client 
computer, said communication session established for the transfer of data 
contained within said server computer, said handoff request including a SYN 
packet and an ACK packet, said SYN and ACK packet used for establishing said 
communication session between said client and said First server computer, said 
ACK packet including a first initial TCP state of said first server computer in said 
communication session, including a first initial TCP sequence number; 

changing a first destination IP address of said SYN packet to a second IP 
address of said server computer, at said BTCP module; 

sending said SYN packet to said TCP module; 

receiving a SYN/ACK packet at said second BTCP module; 

parsing a second initial TCP state from second SYN/ACK packet, 
including a second initial sequence number, for said TCP module, said second 
initial TCP state associated with a second TCP state for said server computer in 
said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said 
second. IP address, at said BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected 
server computer in said communication session; 

sending said ACK packet that is updated to said TCP module; and 

sending a handoff acknowledgment message to said first BTCP module 
over said control channel. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 34. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 34, as the reasoning for rejecting claim 34 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 34 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 34. For instance, Albert fails to teach at 
least the recited "receiving a handoff request from a first BTCP module located at a first server 
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computer within said cluster network over a persistent control channel". As discussed above 
with claim 1 1 , Albert fails to teach a first BTCP module or a persistent control channel. Further, 
Albert fails to teach a "handoff request". Rather, Albert merely teaches that its forwarding 
agents forward packets to a selected back-end server, rather than handing off the TCP 
communication session. Further, Brendel does not appear to be relied upon in the rejection of 
claim 34 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 34 be overturned. 

Dependent Claim 35 

Claim 35 depends from claim 34, which depends from claim 26, and thus claim 35 
inherits all elements of claims 26 and 34. Accordingly, claim 35 is allowable over Albert in view 
of Brendel at least for the reasons discussed above with claims 26 and 34. Additionally, claim 
35 further recites: 

The server computer as described in Claim 34, wherein said method 
comprises the further steps of: 

monitoring traffic associated with handing off said TCP/IP communication 
session to said server computer, at said BTCP module, to parse said second initial 
TCP state of said server computer, said second initial TCP state associated with 
said TCP/IP communication session; and 

sending said second initial TCP state of said server computer to said first 
BTCP module by including said second initial TCP state in said handoff 
acknowledgment, said second initial TCP state including a second initial sequence 
number, such, that said first BTCP module can calculate said second TCP state for 
said server computer in said TCP/IP communication session. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 35. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 35, as the reasoning for rejecting claim 35 appears to be the same as in the Final Office 
Action of April 20, 2005 fin which claim 35 was rejected as being anticipated by Albert), 
However, Albert fails to disclose all elements of claim 35. For instance, A Ibert fails to teach at 
least the recited BTCP module, thus for at least this reason Albert fails to teach the above steps 
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that involve such BTCP module. Further, Brendel does not appear to be relied upon in the 
rejection of claim 35 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 35 be overturned. 

Dependent Claim 36 

Claim 36 depends from claim 34, which depends from claim 26, and thus claim 36 
inherits all elements of claims 26 and 34. Accordingly, claim 36 is allowable over Albert in view 
of Brendel at least for the reasons discussed above with claims 26 and 34. Additionally, claim 
36 further recites: 

The server computer as described in Claim 34, wherein said method 
comprises the further steps of: 

intercepting outgoing response packets from said server computer at said 
second BTCP module; 

changing source addresses of said response packets to said first IP address; 

updating sequence numbers and TCP checksum in said response packets 
to reflect said first TCP state of said first server computer; and 

sending said response packets to said client. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 36. The Final Office Action appeai-s to rely upon Albert as disclosing all elements of 
claim 36, as the reasoning for rejecting claim 36 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 36 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 36. For instance, Albert fails to teach at 
least the recited second BTCP module, thus for at least this reason Albert fails to teach the above 
intercepting step that involves such second BTCP module. Further, Brendel does not appear to 
be relied upon in the rejection of claim 36 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 36 be overturned. 
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Dependent Claim 37 

Claim 37 depends from claim 34, which depends from claim 26, and thus claim 37 
inherits all elements of claims 26 and 34. Accordingly, claim 37 is allowable over Albert in view 
of 'Brendel at least for the reasons discussed above with claims 26 and 34. Additionally, claim 
37 further recites: 

The server computer as described in Claim 34, wherein said method 
comprises the further steps of: 

monitoring TCP/IP control, traffic for said communication session at said 
BTCP module; 

understanding when said communication session is closed at said server 
computer; and 

sending a termination message to said first server computer over said 
control channel. 

The combination of Albert in view of Brendel fails to disclose ail of the further elements 
of claim 37. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 37, as the reasoning for rejecting claim 37 appears to be the same as in the Final Office 
Action of April 20. 2005 (in which claim 37 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 37. For instance, Albert fails to teach at 
least the recited BTCP module and control channel, and thus fails to teacli the above steps that 
involve such BTCP module and control channel. Further, Brendel does not appear to be relied 
upon in the rejection of claim 37 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 37 be overturned. 
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VOL CLAIMS 

A copy of the claims involved in the present appeal is attached hereto as Appendix A. 

Applicant, believes no fee is due with this response. However, if a fee is due, please 
charge our Deposit Account No. 08-2025, under Order No. 10010812-1 from which the 
undersigned is authorized to draw. 
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APPENDIX A 

Claims Involved in the Appeal of Application Serial No. 09/880,631 

1 . In a communication network, a method of TCP state migration comprising the 
steps of: 

a) establishing a TCP/IP communication session between a client computer and a 
first server computer, said first server computer part of a plurality of server computers forming a 
web cluster containing information, said communication session established for the transfer of 
data contained within said information: 

b) handing off said communication session to a selected server computer from said 
first server computer over a persistent control channel using TCP handoff modules that are 
dynamically loadable within TCP/IP stacks in operating systems located at both said first server 
computer and said selected server computer, that implement a TCP handoff protocol that works 
within kernel levels of an existing TCP/IP protocol; and 

c) migrating a first TCP state of said first server computer to said selected server 
computer, and a second TCP state of said selected server computer to said first server computer 
over said control channel. 

2. The method as described in Claim 1 , wherein said step a) comprises the steps of: 
receiving a SYN packet from said client at a first BTCP module located at said first 

server computer; 

sending said SYN packet upstream to a first TCP module located above said first BTCP 

module in a first operating system of said first server computer; 

receiving a first SYN/ACK packet from said first TCP module- 
parsing said first initial TCP state from said first SYN/ACK packet, including a first 

initial sequence number for said first TCP module associated with said TCP/IP communication 

session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said first BTCP module; 

sending said ACK packet to said first TCP module; 
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receiving a web request packet associated with said TCP/IP communication session at 
said first BTCP module at said first server computer; 

storing said SYN, ACK and said web request packet at said first server computer. 

3. The method as described in Claim 2. wherein said step b) comprises the steps of: 
examining content of said web request packet; 

determining which of said plurality of server computers, a selected server computer, can 
best process said WEB request packet, based on said content; 

sending a handoff request from said first BTCP module to a second BTCP module at said 
selected server computer over said control channel, if said selected server computer is not said 
first server computer; 

including said SYN packet and said ACK packet in said handoff request packet; 

changing a first destination IP address of said SYN packet to a second IP address of said 
selected server computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second SYN/ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ACK packet, including a 
second initial sequence number, for said second TCP module, that is associated with said TCP/IP 
communication session; 

changing a second destination IP address of said ACK packet to said second IP address, 
at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected server 
computer in said communication session; 

sending said ACK packet that is updated to said second TCP module; and 

sending a handoff acknowledgment message to said first BTCP module. 

4. The method as described in Claim 3, wherein step c) comprises the steps of: 
monitoring traffic associated with establishing said TCP/IP communication session in 

step a), at said first BTCP module, to parse a first initial TCP state of said first server computer, 
said first initial TCP state associated with said TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over said control 
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channel by including said first initial TCP state in said handoff request packet, said first initial 
TCP state including a first sequence number, such that said second BTCP module can calculate 
said first TCP state for said first server computer in said TCP/IP communication session. 

5. The method as described in Claim 3, wherein step c) comprises the steps of: 
monitoring traffic associated with handing off said TCP/IP communication session at said 

second BTCP module, to parse a second initial TCP state of said selected server computer, said 
second initial TCP state associated with said TCP/IP communication session; and 

migrating said second initial TCP state of said selected server computer to said first 
BTCP module by including said second initial TCP state in said handoff acknowledgment 
packet, said second initial TCP state including a second initial sequence number, such that said 
first BTCP module can calculate said second TCP state for said selected server computer in said 
TCP/IP communication session. 

6. The method as described in Claim 2, comprising the further steps of: 
intercepting a connection indication message sent from said first TCP module to an 

application layer above said first TCP module at a first upper-TCP (UTCP) module, said 
connection indication message sent by said first TCP module upon establishing said 
communication session; and 

holding said connection indication message at said first UTCP module. 

7. The method as described in Claim 6, wherein said method, comprises the further 
steps of: 

sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 

receiving incoming data packets from said client at said first BTCP module; 

changing said destination addresses of said incoming data packets to said second IP 
address; 

updating sequence numbers and TCP checksum in said data packets to reflect said second 
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TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

8. The method as described in Claim 6, comprising the further steps of: 
sending notification from said first BTCP module to said first UTCP module to release 

said connection indication message, if said selected server computer is said first server computer; 

sending incoming data packets, including said web request packet, from said client, 
received at said first BTCP module, upstream. 

9. The method as described in Claim 1, comprising the further step of: 
intercepting outgoing response packets from said selected server computer at a second 

bottom TCP (BTCP) module located at said selected server computer; 

changing source addresses of said response packets to a first IP address of said first 
server computer; 

updating sequence numbers and TCP checksum in said response packets to reflect said 
first TCP state of said first server computer; and 

sending said response packets to said client. 

10. The method as described in Claim 1, comprising the further steps of: 
monitoring TCP/IP control traffic for said communication session at said second BTCP 

module; 

understanding when said communication session is closed at said second server 
computer; 

sending a termination message to said first server computer over said control channel; 

terminating said TCP/IP communication session at said first server computer by 
terminating a forwarding mode at said first BTCP module; and. 

freeing data resources associated with said communication session at said first server 
computer. 

11. In a communication network, a method of TCP state migration comprising the 
steps of: 

a) establishing a TCP/IP communication session between a client computer and a 
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first server computer, said first server computer part of a plurality of server computers forming a 
web cluster containing information, said communication session established for the transfer of 
data contained within said information; 

b) monitoring traffic associated with establishing said TCP/IP communication 
session to understand a first initial TCP state of said first server computer associated with said 
TCP/IP communication session, at a first bottom-TCP (BTCP) module at said first server 
computer; 

c) receiving a web request associated with said TCP/IP communication session at 
said first BTCP module at said first server computer; 

d) examining content of said web request; 

e) determining which of said plurality of server computers, a selected server 
computer, can best process said web request, based on said content; 

1) handing off said communication session to said selected server computer from 
said first server computer over a persistent control channel, if said selected server computer is 
not said first server computer; 

g) monitoring traffic associated with handing off said TCP/IP communication 
session to understand a second initial TCP state of said selected server computer associated with 
said TCP/IP communication session, at a second BTCP module at said selected server computer; 

h) migrating said first initial TCP state to said selected server computer over said 
control channel, such that said second BTCP module can calculate a first TCP state for said first 
server computer in. said TCP/IP communication session; 

i) sending a second initial TCP state of said selected server computer to said first 
BTCP module, such that said first BTCP module can calculate a second TCP state for said 
selected server computer in said TCP/IP communication session; 

j) forwarding data packets received at said first BTCP module from said client to 
said selected server computer, by changing said data packets to reflect said second TCP state and 
a second IP address of said selected server computer; 

k) sending response packets from said selected server computer directly to said 
client computer by changing said response packets to reflect said first TCP state and a first IP 
address of said first server computer; and 
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1) terminating said TCP/IP communication session at said first server computer 
when said TCP/IP communication session is closed. 

12. The method as described in Claim 1 1 , wherein said step a) comprises the steps of: 
receiving a packet from said client at said first BTCP module; 

sending said SYN packet upstream to a first TCP module located above said first BTCP 

module in a first operating system of said first server computer; 

receiving a first SYN/ACK packet, from said first TCP module- 
parsing said first initial TCP state from said first SYN/ACK packet, including a first 

initial sequence number for said first TCP module associated with, said TCP/IP communication 

session; 

sending said SYN/ACK packet to said client; 
receiving an ACK packet from said client at said first BTCP module; 
sending said ACK packet to said first TCP module; 
storing said SYN, ACK and said web request at said first server computer. 

13. The method as described in Claim 1 1 , wherein said step e) comprises the steps of: 
sending a handoff request packet from said first BTCP module to said second BTCP 

module over said control channel; 

including said SYN packet and said ACK packet in said handoff request packet; 

changing a first destination IP address of said SYN packet to a second IP address of said 
selected server computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second SYN/ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ACK packet, including a 
second initial sequence number, for said second TCP module, that is associated with said TCP/IP 
communication session; 

changing a second destination IP address of said ACK packet to said second IP address, 
at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected server 
computer in said communication session; 
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sending said ACK packet that, is updated to said second TCP module; and 
sending a handoff acknowledgment message to said first BTCP module. 
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1 4. The method as described in Claim 13, wherein said ACK packet includes said 
first initial TCP state of said first server computer as provided for in step f). 

1 5. The method as described in Claim 13, wherein said handoff acknowledgment 
includes said second initial TCP state of said second server computer, including a second initial 
sequence number, for said second TCP module, that is associated with said TCP/IP 
communication session as provided for in step i). 

1 6. The method as described in Claim 13, comprising the further steps of: 
intercepting a connection indication message sent from said first TCP module to an 

application layer above said first TCP module at a first upper-TCP (UTCP) module, said 
connection indication message sent by said first TCP module upon establishing said 
communication session; and 

holding said connection indication message at said first UTCP module. 

1 7. The method as described in Claim 1 6, wherein step h) comprises the further steps 

of: 

sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 

receiving incoming data packets from said client at said first BTCP module; 

changing said destination addresses of said incoming data packets to said second IP 
address; 

updating sequence numbers and TCP checksum in said data packets to reflect said second 
TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

1 8. The method as described in Claim 1 1, wherein step k) comprises the steps of: 
intercepting outgoing response packets from said selected server computer at said second 

BTCP module; 

changing source addresses of said response packets to said first IP address; 

updating sequence numbers and TCP checksum in said response packets to reflect said 
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first TCP state of said first server computer; and 

sending said updated response packets to said client. 

19. The method as described in Claim 1 1 , wherein step 1) comprises the steps of: 
monitoring TCP/IP control traffic for said communication session at said second BTCP 

module; 

understanding when said communication session is closed at said second server 
computer; 

sending a termination message to said first server computer over said control channel; 
terminating a forwarding mode at said first BTCP module; and 
freeing data resources associated with said communication session at said first server 
computer. 

20. The method as described in Claim 16, comprising the further steps of: 
sending notification from said first BTCP module to said first UTCP module to release 

said connection indication message, if said selected server computer is said first server computer; 
and 

sending incoming data packets, including said web request, from said client, received at 
said first BTCP module, upstream. 

2 1 . The method as described in Claim 1 1 , wherein each of said plurality of server 
computers is constructed similarly including BTCP modules located downstream from TCP 
modules, and UTCP modules located upstream from TCP modules. 

22. The method as described in Claim 12, comprising the further step of storing said 
web request, said SYN packet, said ACK packet, and said web request at said first server 
computer. 

23. The method as described in Claim 22, wherein said control channel allows for 
communication between all UTCP modules. 
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24. The method as described in Claim 1 1 , wherein said plurality of server computers 
is coupled together over a wide area network in said communication network. 

25. The method as described in Claim 1 1 , wherein said information is 
partitioned/partially replicated throughout each of said plurality of server computers. 
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26. A server computer comprising: 

an upper TCP (UTCP) module located above a TCP module in an operating system of 
said server computer; 

a bottom TCP (BTCP) module located below said TCP module, said UTCP, TCP, and 
BTCP modules implementing a method of handing off a communication session between a first 
node, and second node in a cluster network that works within the kernel level of an existing 
TCP/IP protocol, by migrating TCP states associated with said first and second nodes. 

27. The server computer as described in Claim 26, wherein said method comprises 
the steps of: 

a) establishing a TCP/IP communication session between a client computer and said 
server computer, said first node, said server computer part of a plurality of server computers 
forming said cluster network containing information, said communication session established for 
the transfer of data contained within said information; 

b) receiving a web request, associated with said TCP/IP communication session at a 
first BTCP module at said server computer; 

c) examining content of said web request; 

d) determining which of said plurality of server computers, a selected server 
computer, can best process said web request, based on said content; 

e) handing off said communication session to said selected server computer from 
said server computer over a persistent control channel, if said selected server computer is not 
said server computer; and 

f) migrating a first TCP state of said server computer to said selected server 
computer, and sending a second TCP state of said selected server computer to said server 
computer over said control channel. 

28. The server computer as described in Claim 27, wherein step a) of said method 
comprises the steps of: 

receiving a SYN packet from said client at said BTCP module; 
sending said SYN packet upstream to said TCP module; 
receiving a first SYN/ACK packet from said TCP module; 
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parsing a first initial TCP state from said first SYN/ACK packet, including a first initial 
sequence number for said TCP module associated with said TCP/IP communication session; 
sending said SYN/ACK packet to said client; 
receiving an ACK packet from said client at said BTCP module; 
sending said ACK packet to said TCP module; 
storing said SYN, ACK at said server computer. 

29. The server computer as described in Claim 28, wherein said method comprises 
the steps of: 

sending a handoff request packet from said BTCP module to a second BTCP module over 
said control channel, said second BTCP module located below a second TCP module in a second 
operating system at said selected server computer; 

including said SYN packet and said ACK packet in said handoff request; 

receiving a handoff acknowledgment message at said BTCP module from said second 
BTCP module. 

30. The server computer as described in Claim 29, wherein said step f) of said method 
comprises the steps of: 

monitoring traffic associated with establishing said TCP/IP communication session in 
step a), at said BTCP module, to parse a first initial TCP state of said server computer, said first 
initial TCP state associated with said TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over said control 
channel by including said first initial TCP state in said handoff request, said first initial TCP state 
including a first sequence number, such that said second BTCP module can calculate said first 
TCP state for said server computer in said TCP/IP communication session. 

3 1 . The server computer as described in Claim 29, wherein said method comprises 
the further steps of: 

intercepting a connection indication message sent from said first TCP module to an 
application layer above said first TCP module at a first upper-TCP (UTCP) module, said 
connection indication message sent by said first TCP module upon establishing said 
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communication session; and 

holding said connection indication message at said first UTCP module. 

32. The computer system as described in Claim 3 1 , wherein said method comprises 
the further steps of: 

sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 

receiving incoming data packets from said client at said first BTCP module; 

changing said destination addresses of said incoming data packets to said second IP 
address; 

updating sequence numbers and TCP checksum in said data packets to reflect said second 
TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

33. The server computer as described in Claim 3 1 , said method comprising the further 
steps of: 

sending notification from said BTCP module to said UTCP module to release said 
connection indication message, if said selected server computer is said server computer; 

sending incoming data packets, including said web request, from said client, received at 
said first BTCP module, upstream. 

34. The server computer as described in Claim 26, said method comprising the further 
steps of: 

receiving a handoff request from a first BTCP module located at a first server computer 
within said cluster network over a persistent control channel, said first server computer having 
established a communication session with a client computer, said communication session 
established for the transfer of data contained within said server computer, said handoff request, 
including a SYN packet and an ACK packet, said SYN and ACK packet used for establishing 
said communication session between said client and said first server computer, said ACK packet 
including a first initial TCP state of said first server computer in said communication session, 
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including a first initial TCP sequence number; 

changing a first destination IP address of said SYN packet to a second IP address of said 
server computer, at said BTCP module; 

sending said SYN packet to said TCP module; 

receiving a SYN/ACK packet at said second BTCP module; 

parsing a second initial TCP state from second SYN/ACK packet, including a second 
initial sequence number, for said TCP module, said second initial TCP state associated with a 
second TCP state for said server computer in said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said second IP address, 
at said BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected server 
computer in said communication session; 

sending said ACK packet that is updated to said TCP module; and 

sending a handoff acknowledgment message to said first BTCP module over said control 
channel. 

35. The server computer as described in Claim 34, wherein said method comprises 
the further steps of: 

monitoring traffic associated with handing off said TCP/IP communication session to 
said server computer, at said BTCP module, to parse said second initial TCP state of said server 
computer, said second initial TCP state associated with said TCP/IP communication session; and 

sending said second initial TCP state of said server computer to said first BTCP module 
by including said second initial TCP state in said handoff acknowledgment, said second initial 
TCP state including a second initial sequence number, such that said first BTCP module can 
calculate said second TCP state for said server computer in said TCP/IP communication session. 

36. The server computer as described in Claim 34, wherein said method comprises 
the further steps of: 

intercepting outgoing response packets from said server computer at said second BTCP 
module; 

changing source addresses of said response packets to said first IP address; 
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updating sequence numbers and TCP checksum in said response packets to reflect said 
first TCP state of said first server computer; and 

sending said response packets to said client. 
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37, The server computer as described in Claim 34, wherein said method comprises 
the further steps of: 

monitoring TCP/IP control traffic for said communication session at said BTCP module; 
understanding when said communication session is closed at said server computer; and 
sending a termination message to said first server computer over said control channel. 
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APPENDIX B 

No evidence pursuant to § § 1 . 1 30, 1 . 1 3 1 } or 1 . 1 32 or entered by or relied upon by the 
examiner is being submitted. 
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APPENDIX C 

No related proceedings are referenced in II. above, hence copies of decisions in related 
proceedings are not provided. 
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